Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/isis/isis-minutes-91nov.txt

Text File | 1993-02-17 | 8KB | 198 lines

CURRENT_MEETING_REPORT_

Reported by Ross Callon/DEC

Minutes of the ISIS for IP Internets Working Group (ISIS)

Agenda


  1. Update to ISIS MIB (Chris Gunner)
  2. Update to RFC 1195 (Ross Callon)
  3. ISIS-BGP Interactions (Yakov Rekhter)


Update to ISIS MIB draft

Chris Gunner presented an updated draft of ISIS MIB. The major changes
from the previous draft were:

   o The number of table were reduced from the previous version - now
     there are half as many tables roughly as previously.

   o No restriction on Set PDU's contents in the MIB specification.  An
     agent, however, can impose one on the Set PDU's contents.

There was a suggestion to link the IP destination object and the IP
Forwarding Table.

Additional detail-level reviewers of the ISIS MIB would be appreciated.
It is expected that this will occur at the MIB is implemented.  The
IS-IS MIB is currently an Internet Draft.

Update to RFC 1195

Ross Callon presented an updated version of RFC 1195.  The changes to
RFC 1195 are listed in Section 6 of the new draft (which has been
distributed to the Working Group).

Following changes and topics were discussed:


   o Reference to final International Standard of ISO 10589.  This is
     the biggest change to the draft.  This allows several sections of
     RFC 1195 to be removed as they are redundant with corrections and
     improvements that have been made to ISO 10589.  For example,
     Annexes on encoding of sequence number packets and on
     authentication are now redundant with ISO 10589.

   o The spec now allows announcement of the IP Router ID over
     unnumbered links.  This is needed for Strict Source Routing,
     network management, and for locally originated IP packets over
     unnumbered links.  The spec will be updated to specify that for
     routers which have only unnumbered links, the router ID must be

                                   1





     announced in the LSP's as a Host Route.  The spec should probably
     also include a brief description of what a router ID is.

   o What should be done when a router is a L1 and L2 router, doing RIP,
     but L2 is not IP capable?  The spec now describes this in some
     detail, but some editorial clarification is needed (see the "mixed
     operation" section of the update to RFC 1195).

   o NSAP address for IP-only routers was discussed.  There are several
     ways in which these can be obtained.  This is currently being
     pursued in several other places for uses which include, but which
     go well beyond use in IS-IS. Therefore this should be removed from
     the update to RFC 1195.

   o There was a discussion of how to transition two instances of IS-IS
     which are operating in "Ships in the Night" mode to a single
     instance of Integrated IS-IS. Ross proposed two possible transition
     methods, one of which was well received and the other of which was
     quickly rejected.  Implementations will not be required to be able
     to run two instances of IS-IS in this manner.  However, if an
     implementation does implement the capability of running two
     versions of IS-IS in SIN mode, then the implementation must also
     implement the controls needed to be able to transition from SIN
     mode to integrated mode and vice versa.

   o An optimization of when to leak routes from L1 to L2 was discussed
     and approved.  This would optionally allow selective leaking of
     routes from level 1 to level 2 LSPs, in a manner which not effect
     routes (except for an improvement in routes in one obscure case)
     but which would reduce the amount of information in level 2 LSPs,
     at the cost of slightly more work for the routers doing the route
     leaking.  This feature would work well even when implemented by
     only some routers, and therefore can be optionally implemented and
     deployed.

   o There was a discussion of redundant manually configured summary
     routes.  It was agreed that this issue was not particularly
     important, but that the spec should be complete and unambiguous.
     The decision was that when redundant summary addresses are manually
     configured, both are announced.

   o Dino Farinacci suggested that we can use the LSP protocols
     supported field to avoid creating a black hole when all routers
     within an area are not the same type (all OSI, all IP, or all
     Dual).  Again this was a feature which will work well even when
     implemented by only some routers in an area (routers which do not
     implement this will interwork with those that do).  This proposal
     was accepted.


Ross agreed to update the spec based on this discussion, and to have
this issued as an Internet Draft when available.


                                   2





BGP - ISIS Interaction

Yakov Rekhter presented the issues of interaction between BGP and IS-IS.
After the discussion, Sharad Sanghi of ASN ([e-mail]) and Atul
Bansal ([e-mail]) volunteered to write BGP-IS-IS draft.

Leakage of routes between BGP and IS-IS was discussed, and it was agreed
that this should be the same as in the OSPF-BGP case.

The relationship between BGP router IDs and IS-IS router IDs was
discussed.

Piggybacking of BGP information in IS-IS packets was discussed.  In
those cases where all or most level 2 routers are border routers running
BGP, this makes sense (IS-IS solves the n-square BGP link problem, and
provides reliable multicast mechanism).  However, in those cases where
very few level 2 routers are border routers, the n-square link problem
is not significant, and piggybacking requires non-border routers to
store BGP information.  It was therefore agreed that whether to
piggyback BGP information on IS-IS packets or to run internal BGP will
depend upon the network environment, and therefore both possibilities
should be allowed.  If a network has very few BGP speakers then I-BGP is
a good solution.  If a network has lots of BGP speakers and very few
non-BGP speaking L2 routers then Piggybacking is most efficient.

Auto-configuration of I-BGP neighbors was also discussed.  Auto I-BGP
configuration optimization was suggested as an efficient mechanism for
discovering I-BGP neighbors.  This feature eliminates the nightmare -
manual configuration of I-BGP neighbors.  This autoconfiguration can be
piggybacked on IS-IS.

Tagging is currently defined by RFC 1195.  This should continue to be
available.

We also discussed how to pass BGP information between two I-BGP
neighbors when one is doing OSPF and the other is doing ISIS? This
required close cooperation with the folks working on BGP-OSPF
interactions.

Attendees

Atul Bansal              [e-mail]
Robert Blokzijl          [e-mail]
Daniel Blum              [e-mail]
David Bolen              [e-mail]
Ross Callon              [e-mail]
Ken Carlberg             [e-mail]
Dean Cheng               [e-mail]
Chi Chu                  [e-mail]
Kurt Dobbins             [e-mail]
Dino Farinacci           [e-mail]
Chris Gunner             [e-mail]
Christine Hemrick        [e-mail]
Tony Li                  [e-mail]

                                   3





April Merrill            [e-mail]
Dave Monachello          [e-mail]
Dennis Morris            [e-mail]
Yakov Rekhter            [e-mail]
Manoel Rodrigues         [e-mail]
Sharad Sanghi            [e-mail]
Harvey Shapiro           [e-mail]
Ravi Srinivasan          [e-mail]
Andrew Veitch            [e-mail]
Cathy Wittbrodt          [e-mail]
Osmund de Souza          [e-mail]



                                   4